2000년 이후로 Fortune 500 기업의 반이 사라졌습니다.

→ Disruptive Business Models

Ex) Uber was a big disruption (was it GPS? 전자결제? 스마트 폰?) → 우버는 이 3개를 합친 BM(business model)을 만듬.

→ 택시 회사는 이것을 이겨내기 위해 개발자가 앱을 만들었어야

이전에는 비디오, DVD ⇒ 넷플릭스는 DVD 배송 모델 → 인터넷

기술을 혁신을 가능케 함 혁신적인 비즈니스 모델의 중요성

DevOps 정의

lean & agile 원리를 따르고, dev 와 ops 가 상호협력하는 것

새로운 문화를 요하고, 새로운 앱 디자인, 자동화 레버레징, programmable platform

데브옵스가 아닌것: 별개의 팀, 데브와 옵스를 합치는 것, 툴이 아님, not a one size fits all, 단순 자동화

Agile development environment?

목표가 무엇인가?

Agility: devops, microservices, containers 3가지의 공통 분모

devops: 스피드와 agility, microservices: 작은 단위 배포, containers: ephemeral runtime

Waterfall Method 의 문제

Requirements ⇒ Design ⇒ Code ⇒ Integration ⇒ Test ⇒ Deploy

Very Error prone, can’t know if there is a problem during the process till test(Very High Risk). No Provision for changing requirements.

각 단계가 시작과 끝이 있어서 단계별로 다 끝나야 되돌아봄, 팀이 다 따로 놈

XP, Agile, and Beyond

• Extreme Programming(XP)

-including pair programming

• Agile Manifesto

  1. 요구사항
  2. 플랜
  3. 디자인
  4. 개발
  5. 배포
  6. 트랙, 모니터

  유기적으로

  Partrick Debois - 2009 Father of devops

  M1 Summary and Highlights

  Congratulations! You have completed this lesson. At this point in the course, you know:

  • Technology is the enabler of innovation, rather than the driver of innovation. You must have an innovative business idea to leverage technology.
  • In 2009, John Allspaw described an innovative approach to managing development and operations that enabled Flickr to complete over ten deploys per day, when many companies were completing fewer than one deploy every six months. This was a key moment in the growth of DevOps.
  • DevOps is the practice of development and operation engineers working together during the entire development lifecycle, following Lean and Agile principles that allow them to deliver software in a rapid and continuous manner.
  • DevOps is not it is not just Dev and Ops working together. It is a cultural change and a different way to work. DevOps has three dimensions: culture, methods, and tools. Of these, culture is the most important.
  • The essential characteristics of DevOps include cultural change, automated pipelines, infrastructure as code, immutable infrastructure, cloud native application design, the ecosystem of containers, and how to deploy with immutable infrastructure.
  • DevOps started in 2007 when Patrick Debois and Andrew Clay Shafer began to gather like-minded people together at conferences to talk about common experiences.
  • In 2009, Allspaw delivered his now famous “10+ Deploys Per Day – Dev and Ops Cooperation at Flickr” presentation and the idea gained ground. Also in 2009, Patrick Debois started a conference called DevOpsDays that helped spread the DevOps message.
  • Books such as Continuous Delivery in 2010, The Phoenix Project in 2013, and The DevOps Handbook in 2016, helped practitioners understand how DevOps worked.
  • The major influential people of the early DevOps movement: Patrick Debois, Andrew Clay Shafer, John Allspaw, Jez Humble, Gene Kim, John Willis, Bridget Kromhout, and Nicole Forsgren, went out and made a difference, showing the results that could be achieved with DevOps.
  • The message spread from practitioner to practitioner until they began to realize what was possible with DevOps and that it was a better way to work.

M2 Summary and Highlights

Congratulations! You have completed this lesson. At this point in the course, you know:

• Social coding is coding as a community and public repositories and pair programming result in higher code quality.
• Working in small batches reduces waste and means quickly delivering something useful to the customer.
• Minimum viable product is as much about delivery as it is about building what the customer really desires.
• Test driven development is writing the test for the code you wish you had, then writing the code to make the test pass. It allows you to develop faster and with more confidence.
• Behavior driven development focuses on the behavior of the system from the outside in. It looks at the system as a consumer of it.
• Behavior driven development improves communication by using an approachable syntax that developers and stakeholders can understand.
• Microservices are built around business capabilities and are independently deployable by fully automated deployment machinery.
• Cloud native architecture enables independently deployable microservices that take advantage of horizontal scaling and result in more resilient services.
• Failure is inevitable, so we design for failure rather than trying to avoid failure.
• It is important to embrace failure and quickly recover when failures happen.

M3 Summary and Highlights

Congratulations! You have completed this lesson. At this point in the course, you know:

• Taylorism was designed for factory work and software development is bespoke, that is, more like craftwork, and that working in silos leads to mistakes and bottlenecks.
• Team ownership and stable teams make software development more like product development rather than project management.
• Developers want innovation, while Operations want stability.
• Required DevOps behaviors include shared ownership, collaboration, embracing change, and data-driven responses.
• Infrastructure as Code is describing infrastructure in a textual executable format.
• Ephemeral infrastructure can be used and then discarded because servers are built on demand, via automation, using Infrastructure as Code techniques.
• Continuous Integration is building, testing, and integrating every developer change into the master branch after tests have passed.
• The benefits of Continuous Integration include faster reaction time, moving faster, and reducing the risk in integrating code.
• Continuous Delivery ensures that code can be rapidly and safely deployed to production by delivering every change to a production-like environment.
• The five principles of Continuous Delivery have to do with quality, working in small batches, automation, continuous improvement, and shared responsibility.

M4 Summary and Highlights

Congratulations! You have completed this lesson. At this point in the course, you know:

• Organizations need to have small, dedicated, cross-functional, self-organizing teams to successfully implement DevOps.
• Conway’s Law implies that a company’s design results are a direct reflection of the company’s communication structure.
• Instead of the traditional structure organized around technology, successful DevOps teams should be organized around business domains. Each team should have its own mission that aligns with a business domain.
• DevOps is a mindset that the whole organization adopts.
• DevOps solves problems caused by siloed teams.
• DevOps is the practice of development and operations engineers working together during the entire software lifecycle, following lean and Agile principles that allow them to deliver high-quality results.
• Actions without consequences can lead to apathy.
• Allowing teams to feel the effect of their actions fosters empathy, resulting in higher-quality work.
• The organizational objective of DevOps is to attain a shared mindset and empower everyone to deliver customer value.